What Is BaaS? Banking-as-a-Service for Engineering Teams

In April 2024, Banking‑as‑a‑Service provider Synapse filed for Chapter 11 bankruptcy. Regulators later identified a shortfall of roughly $60–90 million between bank‑held funds and amounts owed to end users. Many customers of fintechs like Yotta and Juno were locked out of their accounts while tens of millions in deposits were frozen. The failure exposed what happens when the internal ledger above a BaaS API is missing or improperly built.

Engineering teams building fintech products, marketplaces, wallets, or neobanks need access to regulated banking rails without having to become a bank. Banking-as-a-Service (BaaS) is the model that provides it, and it shapes how your team designs accounts, payments, and money movement from day one.

BaaS application programming interfaces (APIs) give you access to accounts, cards, transfers, and payouts rails so you can embed banking features inside your product without holding a charter. The operational money architecture your product needs sits beyond that API access.

Between the BaaS API and a working financial product lies a layer of engineering work your team must build: internal ledgering, reconciliation, state management, omnibus account attribution, and multi-provider coordination.

What is Banking-as-a-Service?

Banking-as-a-Service is a delivery model in which a licensed bank exposes its regulated capabilities through programmable APIs. A non-bank company consumes those APIs to embed banking features into its own product under its own brand. The license, capital requirements, regulatory reporting, and money-handling responsibilities stay with the sponsor bank.

Fintechs and software platforms can therefore launch banking features (accounts, cards, payments, and lending) without becoming licensed banks themselves. The sponsor bank retains accountability for program-level risk management, even when the BaaS provider runs day-to-day risk operations.

The BaaS architecture has four layers:

Holds the charter, Federal Deposit Insurance Corporation (FDIC) deposit insurance, and connections to interbank payment networks such as the Automated Clearing House (ACH), Fedwire, and card networks. It is supervised by the Office of the Comptroller of the Currency (OCC), the FDIC, or the Federal Reserve.

Packages the bank's capabilities into Representational State Transfer (REST) and JavaScript Object Notation (JSON) APIs, with endpoints for accounts, payments, cards, and compliance.

Consumes those APIs to build the user experience, onboarding flow, business logic, and operational workflows.

Interact with your product. The licensed bank and BaaS platform are invisible to them. The bank is accountable for the actions and compliance of its third-party partners. That accountability constrains what can be delegated and what your engineering team must build.

Your code calls an API, the API calls the bank, and a few layers of translation happen in between.

How the BaaS Model Works in Practice

The BaaS model routes your product's API calls through a middleware layer that sits between the licensed bank's core systems and your product, translating the bank's internal capabilities into the REST and JSON interfaces your engineers consume. The middleware has three sub-components.

Enforces security policies (authentication, rate limiting, routing) across the underlying banking microservices.

Each banking capability is an independent service:

Normalizes differences in settlement timing and protocol so your product layer specifies payment intent rather than rail-specific parameters.

When your product initiates an ACH debit, for example, the BaaS platform verifies the account, constructs the ACH file, and performs compliance checks. The sponsor bank, registered as an Originating Depository Financial Institution, submits the file to the ACH network. Settlement follows. Your product updates displayed balances, which may precede actual settlement.

Your engineers write API calls while the bank holds the regulatory perimeter. The BaaS platform translates between your code and the bank's core systems. However, BaaS gets used interchangeably with three other terms, which causes problems when teams evaluate providers.

BaaS vs. Adjacent Models

Three terms often get used interchangeably with BaaS: embedded finance, open banking, and core banking. However, each describes a different layer of the stack.

Understanding where BaaS fits among adjacent models helps your team evaluate providers in context. It also helps you understand the different types of BaaS platforms.

The Different BaaS Provider Platforms

BaaS providers fall into different structural categories, each with different API surfaces and integration realities: sponsor-bank-led, middleware and API platforms, and modern-core platforms.

Sponsor-bank-led platforms

A licensed bank directly exposes its charter and core infrastructure. The API layer is often built on or adjacent to a legacy core banking system that is not designed for programmatic access, so engineering teams may encounter polling and latency constraints, as well as inconsistent error models. Regulatory scrutiny of sponsor-bank relationships has grown in recent years.

Middleware and API platforms

An intermediary sits between sponsor banks and your product, aggregating bank relationships and normalizing APIs. Developer experience improves, but the middleware provider's relationships with banks become a dependency for your product. If the middleware provider loses its relationship with its sponsor bank, downstream products can be disrupted.

Modern core banking platforms

Cloud-native platforms built with an API-first model expose each banking capability as an independent microservice. Geographic coverage is bounded by where the platform holds licenses.

Geographic scope shapes provider choice. A US sponsor bank relationship does not provide European payment rail access, and separate provider relationships are required per jurisdiction, with distinct API contracts, data residency requirements, and compliance rules in each.

The BaaS provider gives you rails and a license, but your team must build infrastructure.

What Engineering Teams Build on Top of BaaS

Engineering teams build six categories of infrastructure atop BaaS: an internal ledger, reconciliation, idempotency, state management, omnibus attribution, and card controls. BaaS APIs provide payment rails, account opening, and regulatory coverage, but your product still needs an internal financial system to use them safely in production.

1. Internal double-entry core ledger

A double-entry core ledger is the authoritative book of record your product runs against, separate from the bank's records. BaaS providers send transaction events representing the bank's view of money movement. Your team maintains an independent ledger in which every debit equals a credit and the postings balance across all transactions.

Many early-stage companies track funds in spreadsheets or rely on transaction logs from payment processors. Those approaches break down at scale.

Your ledger must distinguish between posted balance (settled transactions), pending balance (authorized but unsettled), and available balance (what the user can spend). Concurrency controls on ledger writes prevent race conditions on simultaneous updates. Balances are often derived from an append-only event log rather than stored as mutable state.

If a user has $500 USD settled in their account and authorizes a $40 purchase, the authorization is in flight but remains unsettled with the bank. In the ledger, this becomes a pending transaction that reduces available funds while increasing the amount on hold; posted remains at $500, pending becomes $40, and available becomes $460.

Later, when the merchant captures the transaction, a second balanced transaction moves 40 from the hold bucket into a settlement account, updating posted and pending without ever mutating balances in place.

2. Reconciliation between bank events and internal state

Reconciliation aligns what the bank says happened with what your internal ledger recorded. BaaS providers send settlement files and webhook events representing the bank's view. Your internal ledger holds your view. The two can diverge in practice.

Under an omnibus account structure, reconciliation is a three-party problem. Your sub-ledger must reconcile to the transaction source data, and the transaction source data must reconcile against the bank's core.

3. Idempotency for payment operations

Idempotency controls prevent a single payment instruction from being executed more than once. A payment is processed by the BaaS provider, but the response fails to reach your system due to a network error, so the client retries. Without idempotency controls, a retry can result in a double charge.

Idempotency is usually implemented at three layers: the API layer (idempotency-key headers), the webhook consumption layer (event deduplication), and the database layer (unique key constraints). BaaS APIs expose the payment action, but teams build the surrounding idempotency infrastructure themselves.

4. Money movement state management

Money movement state management tracks each payment through every stage of its lifecycle. Each payment runs through an internal state machine covering pending, submitted, in-flight, partially settled, failed, retried, canceled, and reversed states.

BaaS providers give API endpoints for initiating payments and webhooks for terminal state notifications. Your team builds the state machine that manages the full lifecycle across failure scenarios.

5. Omnibus account fund attribution

Omnibus account fund attribution determines which portion of a pooled bank account belongs to which individual customer. Customer funds in BaaS architectures are often pooled in For the Benefit Of (FBO) accounts at the sponsor bank.

The BaaS provider maintains the pooled account. Your team owns the sub-ledger that tracks per-customer balances and keeps the attribution synchronized in real time.

6. Card controls, permissions, and product logic

Card controls, permissions, and product logic govern how cards behave once issued. Spend limits, merchant category restrictions, user-level permissions, and the rules governing when cards are active or frozen live in your product layer. The BaaS provider supplies card issuance and authorization infrastructure. Your team writes the product-layer rules that govern how that infrastructure gets used.

These six categories make up the operational layer above your BaaS rails, with the ledger at its center. How your team builds that ledger shapes what your product can do.

The Ledger in the Center of Your BaaS Infrastructure

The ledger you build determines what your BaaS product can do. It determines how easily you can switch providers, pass an audit, or scale into new asset types and markets.

BaaS rails do not give you that ledger, or the reconciliation, idempotency, state management, omnibus attribution, and card controls around it. Your team builds and owns that layer, in-house or with a platform built for it.

Formance offers an open-source ledger (under an MIT license) as the source of truth, with Connectivity for provider abstraction, Reconciliation for drift detection between internal positions and bank statements, and Flows for multi-step workflows like hold funds, await KYC, and trigger payout.

Clone the Formance Ledger on GitHub, run it locally, and post your first transaction.

FAQs about Banking-as-a-Service (BaaS)

What is Banking-as-a-Service?

Banking-as-a-Service is a delivery model in which a licensed bank exposes regulated banking capabilities (accounts, payments, cards, KYC) via APIs that non-bank companies consume to embed banking features in their products.

Do I need a banking license to use BaaS?

No. The sponsor bank holds the license and remains legally accountable for regulatory compliance. Your team may still need to implement Bank Secrecy Act and Anti-Money Laundering (BSA/AML) programs, KYC workflows, and audit logging as required by the sponsor bank agreement.

What does a BaaS provider handle?

The licensed sponsor bank handles the banking license, deposit insurance, payment-rail access, and regulatory reporting. Non-bank BaaS platforms act as intermediaries rather than licensed entities. Your team builds account lifecycle logic, balance display, payment state management, internal ledgering, reconciliation, card controls, and all product-level business logic.

Can I switch BaaS providers later?

Technically, yes, but the difficulty depends on how tightly coupled your product is to the provider's data model and API contract. If your internal state management relies on a canonical internal ledger rather than the provider's data model, switching providers means updating the integration layer rather than rewriting product logic.